1. Field of the Invention
The present invention generally relates to computer systems and software. More particularly, the present invention relates to a system and method of providing a reusable connection handle for connections, which operate within a particular sharing scope, preferably within a Java 2 Platform, Enterprise Edition (J2EE) software environment.
2. Description of the Prior Art
The Java 2 Platform, Enterprise Edition (J2EE) is a software standard for developing multitier enterprise applications. The J2EE architecture has a client tier, middle tier, and back-end tier. The client tier supports a variety of client types, and the middle tier supports client services and business logic through Web and Enterprise Java Beans (EJB) containers in the middle tier. The back-end tier includes the enterprise information systems (EIS) in the EIS tier and many standard APIs for accessing databases. One of skill in the art can accordingly alter the objects and components resident on the several tiers. “Containers” are standardized runtime environments that provide services to components on the platform. All containers provide runtime support for responding to client requests and returning results to clients. The containers also provide APIs to support user session management. One of the APIs provided in the J2EE platform is the Java Naming and Directory Interface (JNDI) which is the API for accessing information in enterprise name and directory services.
Resident within the J2EE architecture is the “resource adapter” that plays a central role in the integration and connectivity between an EIS and an application server and serves as the point of contact between application components, application servers and enterprise information systems. A resource adapter and other components, must communicate with one another based on the well-defined “contract” defined by the J2EE Connector Architecture. To enable seamless integration with an application server, a resource adapter abides by system-level contracts defined by the connector architecture. These contracts exist between the application server and the EIS, and are implemented through the resource adapter. The contracts specify how a system external to the J2EE platform integrates with it by supporting basic functions handled by the J2EE container. There are three major contracts: the “connection management contract” which allows applications to connect to an EIS, and enables the application server to utilize pooling; the “transaction management contract” which allows an application server to manage and perform transactional access across one to many EIS resource managers; and the “security contract” which provides support for secure access to the EIS.
On a J2EE platform, a “ManagedConnection” interface provides an application-level connection handle from the EIS to the resource adapter's ManagedConnection instance. The interface also provides methods, such as “cleanup,” to reinitialize the instance and free resources after communication ceases. The instance does not close the connection, however, as such function is required by the application server so connection pooling can be utilized. Thus, a Connection Manager's (CM) job, within a Web Application Server, is to acquire, on behalf of users, connections to various backend resource managers (RMs), such as DB2, involve the resource manager in the server's transactions, and manage the connection life cycle, which includes pooling the connection and resources for reuse. In addition, the Java 2 Connector (J2C) architecture specification defines two characteristics of how connections can be rendered by the CM to the user: shareable and non-shareable. Also, within the J2C Architecture, the CM interacts with the Resource Adapter to create and destroy connections and receive notifications about life cycle events regarding the usage of that connection. The CM requests that the RA create a ManagedConnection (MC) that the CM manages. From the managed connection the CM obtains a “connection,” or “handle” to the connection, which the CM then hands back to the requesting user. When users request non-shareable connections within the J2EE platform, the CM ensures that only one handle is handed out for a specific MC. And for shareable connections, more than one handle for a specific MC can be allocated by the CM and several users can share that MC. The sharing ability of connections allows the J2EE platform to have excellent performance and utilization of system resources.
The J2C specification also permits users to hold connection handles across multiple sharing scopes (i.e., multiple transactions) because the users should be able to iteratively access the resources in the same manner without having to obtain a new connection handle. In the case of shareable connections, it is very desirable to only allow sharing within a well-defined sharing scope. As an example, when multiple handles are used within the same transaction, the handle can share a single MC (assuming the usage properties are the same). Consequently when a sharing scope ends, it is insured that the handle is no longer associated with the managed connections to avoid unnecessary allocation of resources and to avoid future uses of the handles in different sharing scopes while being associated with the same MC. However, the system must also insure that the next time the user requires use of the handle the user holds, the handle is associated to an appropriate MC in a transparent fashion. A problem accordingly arises in that it is difficult to properly reassociate handles with managed connections when the sharing boundary ends.
The J2C specification however provides no means by which a handle can be “disassociated” when the sharing boundary, such as a transaction, goes out of scope. The J2C connection handle only has one active state and must be associated with a MC. If the handle is not associated with an MC it is in an invalid state and is no longer usable. In. the prior art, if nothing special is done, when the sharing scope/transaction ends, a cleanup method is called on the MC and the MC is returned to the free pool. The cleanup call forces all handles associated with that MC into an invalid state, thus the next time the user tries to use that handle, the user will get an exception.
To avoid this, in the existing architecture, the handle associated with a MC is “parked” before the cleanup call is made, thus keeping the handles valid. In operation, when a connection handle is first assigned to a user, it is in a state such that it is associated with a MC. The MC provides a method, called “associateConnection( )” which allows a connection handle that is associated with a MC to be associated with a new MC. “Parking” refers to the process by which the application server gets a connection specifically to allow handles, which are currently not actively being used, to be associated with it, or a “parking connection.” At some time before the end of the sharing scope, and thus before the cleanup method is called on the MC, all handles must be “parked” against the “parking connection” via the MC's associateConnection method. Then when the cleanup method is called on the MC there are no longer any handles associated with it and no handles become invalid. Before the user of the handle may desire to use the handle again, the handle will have to be moved off of the parking MC and on to an MC appropriate for the current sharing scope the user is entering, i.e. a “reassociation” occurs. Unfortunately, significant performance overhead is possible because a component may hold multiple handles. When a method is requested to run on the component, the container does not know if any or all of the handles will actually be used, thus the container must reassociate all handles even if they are not used. Furthermore, when the method ends, if the end of the method also corresponds to the end of the sharing scope, or the sharing scope ends, the container must then park all handles the component holds, even if those handles were not used.
Summarizing the prior art system on a J2EE platform, just prior to the end of a sharing scope of a transaction, the user's handle is reassociated to a “parking” connection to keep the connection handle valid and thus transferable on the platform. Then the MC cleanup method is called and the ManagedConnection is put back in the free pool. Next, prior to a method call on the user's component (the component holding the connection handle(s)), because the user might require the use of one of its connection handle(s), the call on the component is intercepted (during preinvocation processing) and the handle is reassociated off of the parked connection and onto a valid connection for the current sharing scope.
The prior art solution provides several problems in operation due to its significant performance overhead. One problem occurs since all connections are used within a component, such as an Enterprise Java Bean (EJB), and an entity (called a “container”) that manages the life cycle of these components and intercepts all calls to the components use up significant system resources in managing connection handle association. In the prior art system, when a sharing boundary for a resource ends, any handle to connections involved in that sharing boundary will need to be “parked” to a different MC such that the current MC with which the handle is associated is able to have the cleanup method called without invalidating the associated handle(s) before the MC is placed into the free connection pool. This explicit protocol must be used because a shareable connection cannot be used outside of a sharing boundary, otherwise if two components share a connection in a sharing boundary after the boundary ends without parking the handle, both components could become involved in two different sharing boundaries which is an invalid operation. And if the MC is not timely released back to the free connection pool when the component is not using it, all of the available connections in the pool can become allocated with some users unable to acquire free managed connections.
Moreover, the ability to park connection handles requires that the container track information about the handles a particular component is using. Every time a method is called on a component, any handles that component contains will have to be put in a useable state, i.e. reassociated with a real connection in any currently active transaction, whether or not that method uses the handle. The prior art system thus requires significant overhead both in terms of tracking the handle information per component, and in retrieving a connection(s) when the connection was not before needed. Furthermore, if a component has more than one handle and a method is called within the scope of a global transaction, the connections are required to become part of a distributed, two-phase commit transaction, which has even greater associated performance overhead on the system even if neither of the handles is used. Therefore, the prior art system and method to manage connection handles through parking has unsatisfactory overhead demands.
It would therefore be advantageous to provide a software architecture within the J2EE platform, or like software platform, that allows the reassociation of handles without needing to park the handles and utilize significant system resources. Such system and method should minimize the possibility of causing an invalid transaction on the system from improperly maintaining the scope of a handle across a sharing boundary. It is to the provision of such an improved software architecture that the present invention is primarily directed.